Skip to content

Fix UnwrapUnsafeBinder handling in borrow conflict detection #147796

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix UnwrapUnsafeBinder handling in borrow conflict detection #147796

wants to merge 1 commit into from

Conversation

mohammadamin382
Copy link

Summary

Replace todo!() with proper conflict analysis for UnwrapUnsafeBinder projection elements in places_conflict.rs. UnwrapUnsafeBinder is treated as a transparent wrapper that doesn't affect place aliasing, returning EqualOrDisjoint when both projections match.

Changes

  • Modified place_projection_conflict() to handle UnwrapUnsafeBinder projections correctly
  • Reordered pattern matching arms to avoid unreachable patterns

Testing

// Test for borrow conflict detection with UnwrapUnsafeBinder projection elements.
// This ensures that UnwrapUnsafeBinder is properly handled as a transparent wrapper
// that doesn't affect place aliasing analysis.


use std::ops::DerefMut;

struct Container<T> {
    value: T,
}

fn test_same_unwrap_unsafe_binder<T>(x: &mut Container<T>) {
    let r1 = &mut x.value;
    let r2 = &mut x.value; //~ ERROR cannot borrow `x.value` as mutable more than once
    drop(r1);
    drop(r2);
}

fn test_different_fields<T, U>(x: &mut (Container<T>, Container<U>)) {
    let r1 = &mut x.0.value;
    let r2 = &mut x.1.value; // OK: different fields
    drop(r1);
    drop(r2);
}

fn test_nested_unwrap_unsafe_binder<T>(x: &mut Container<Container<T>>) {
    let r1 = &mut x.value.value;
    let r2 = &mut x.value.value; //~ ERROR cannot borrow `x.value.value` as mutable more than once
    drop(r1);
    drop(r2);
}

fn main() {}

Test Results

error[E0499]: cannot borrow `x.value` as mutable more than once at a time
  --> $DIR/borrow-unwrap-unsafe-binder-conflict.rs:13:14
   |
LL |     let r1 = &mut x.value;
   |              ------------ first mutable borrow occurs here
LL |     let r2 = &mut x.value;
   |              ^^^^^^^^^^^^ second mutable borrow occurs here
LL |     drop(r1);
   |          -- first borrow later used here

error[E0499]: cannot borrow `x.value.value` as mutable more than once at a time
  --> $DIR/borrow-unwrap-unsafe-binder-conflict.rs:27:14
   |
LL |     let r1 = &mut x.value.value;
   |              ------------------ first mutable borrow occurs here
LL |     let r2 = &mut x.value.value;
   |              ^^^^^^^^^^^^^^^^^^ second mutable borrow occurs here
LL |     drop(r1);
   |          -- first borrow later used here

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0499`.

Verification

The test correctly identifies borrow conflicts when the same place is borrowed mutably multiple times, demonstrating that UnwrapUnsafeBinder is properly handled as a transparent projection that preserves aliasing semantics.

@mohammadamin382
Fix UnwrapUnsafeBinder handling in borrow conflict detection
62570c2 
Replace `todo!()` with proper conflict analysis for `UnwrapUnsafeBinder` projection elements in `places_conflict.rs`. `UnwrapUnsafeBinder` is treated as a transparent wrapper that doesn't affect place aliasing, returning `EqualOrDisjoint` when both projections match.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 17, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 17, 2025

r? @madsmtm

rustbot has assigned @madsmtm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@mohammadamin382
Copy link
Author

r? @madsmtm

@rustbot
Copy link
Collaborator

rustbot commented Oct 17, 2025

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

@madsmtm
Copy link
Contributor

madsmtm commented Oct 18, 2025 •
edited
Loading

This is probably too far outside my area of expertise

r? compiler-errors (since you authored #130514)

@rustbot rustbot assigned compiler-errors and unassigned madsmtm Oct 18, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 18, 2025

compiler-errors is not on the review rotation at the moment.
They may take a while to respond.

@mohammadamin382
Copy link
Author

r? lcnr

@rustbot rustbot assigned lcnr and unassigned compiler-errors Oct 18, 2025
@lqd
Copy link
Member

lqd commented Oct 18, 2025

Was this PR AI generated?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@lcnr lcnr

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@mohammadamin382 @rustbot @madsmtm @lqd @compiler-errors @lcnr